Carrier Ethernet is evolving to support the needs of the carrier network environment. Carrier Ethernet requires scalable, reliable, and dynamic mechanisms to support operations, administration, and management (OAM) and traffic engineering (TE). Standards have been developed in the Metro Ethernet Forum (MEF), International Telecommunication Union (ITU), Institute of Electrical and Electronics Engineers (IEEE), and the like providing many of these required extensions. Specifically, Connectivity Fault Management (CFM) is an Ethernet standard to provide many common OAM functions associated with underlying network transport for services. For example, CFM is defined in IEEE 802.1ag-2007 IEEE Standard for Local and Metropolitan Area Networks Virtual Bridged Local Area Networks Amendment 5: Connectivity Fault Management, the contents of which are herein incorporated by reference. Also, OAM functions are also defined in ITU-T G.8013/Y.1731 (07/2011) “OAM functions and mechanisms for Ethernet based networks,” the contents of which are herein incorporated by reference. Further, the MEF also defines Ethernet OAM in various technical specifications, such as MEF 17 (04/2007) “Service OAM Requirements & Framework,” the contents of which are herein incorporated by reference. Variously, CFM enables definition of maintenance domains, their constituent maintenance points, and the managed objects required to create and administer them; definition of relationships between maintenance domains and the services offered by Virtual Local Area Network (VLAN)-aware bridges and provider bridges; description of protocols and procedures used by maintenance points to maintain and diagnose connectivity faults within a maintenance domain; and the like.
Conventionally, there is no standard way to reserve service bandwidth across a Layer 2 (L2) network when bandwidth is provisioned on user-network interface (UNI) or an External Network-Network Interface (E-NNI) ports other than to manually configure bandwidth on all intermediate nodes (with associated network-network interface (NNI) ports). Note, such an implementation exists in Internet Protocol (IP)/Multiprotocol label switching (MPLS)-based networks using Resource Reservation Protocol (RSVP)/RSVP-Traffic Engineering (RSVP-TE)/Constraint-based Routing Label Distribution Protocol (CR-LDP). RSVP reserves bandwidth for services across IP networks, and RSVP-TE extends this solution to MPLS LSPs (Label Switched Paths). This results in better predictability of traffic getting passed through the IP/MPLS network. This is a serious shortcoming of conventional L2 networks when E-Line services are provisioned with certain bandwidth guarantee parameters that no standard mechanism is available to test and configure these parameters across an end-to-end path of the service. E-Line services are point-to-point Ethernet Virtual Connections (EVCs) between two UNIs. The E-Line services can provide symmetrical bandwidth for data in either direction with a Committed Information Rate (CIR) and associated Committed Burst Size (CBS), Excess Information Rate (EIR) and associated Excess Burst Size (EBS), delay, jitter, and loss between the UNIs. The E-Line services can provide connections analogous to Time Division Multiplexed (TDM) private line services. The Traffic Engineered parameters of E-Line services only get provisioned on UNI ports of the network. This may result in over-subscription in network and becomes cumbersome for network administrators to add new services with desired service bandwidth on the network.
To overcome this limitation, network administrators can provision the desired bandwidth manually on the entire E-Line service network path, including intermediate network-network interface (NNI) ports. However, this process is time consuming and requires network administrators to login into all downstream nodes to reserve the bandwidth parameters. Additionally, manual allocation has challenges in guaranteeing L2 service behavior in cases where the run-time topology changes. If the network administrator chooses to reserve bandwidth for L2 service on backup path, this would be waste bandwidth which could be allocated to some other L2 service. If the network administrator does not reserve bandwidth on the backup path, service behavior cannot be guaranteed after switchover to the backup path. Also, if in the future, the network administrator wants to readjust bandwidth parameters, they will be required to login again into all participating nodes and reconfigure the network. This whole process is time consuming, which leads to slower turn up time for operators and results in revenue loss to the operator.